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Abstract 

The topic for this Master's Thesis is selected in compliance with the guideHnes to 
complete a Master of Science in Applied Computer Science at Columbus State 
University. The problem to be addressed by this thesis is to produce an open standard for 
an m-commerce financial transaction processing system based on current e-commerce 
standards and mobile technology. Ihis solution v/as to be specifically designed to build 
upon the strengths of a mobile platform using current smartphone and tablet technology. 

An open source software stack in com.bination with a cloud computing solution was 
used to create a working example of the specification. Load testing and Denial of 
Service attack testing were completed to test the stability and capacity of the 
implementation. It was found that the initial implementation of the specification was able 
to accommodate a moderate level of concurrent transactions and connected users. It was 
also found that the system was brought down with a slow header denial of service attack, 
but was able to withstand a slowloris denial of service attack. An Android native 
application was built as a sample implementation of a mobile client for the system. 
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Chapter 1: Introduction 

Mobile technology has rapidly evolved over the last 20 years. As a platform, mobile 
devices have evolved their functionality, beginning with basic voice communication and 
later adding text-based communication. As mobile devices gained additional 
capabilities, data and world wide web (WWW) functionality was added. "Not so long 
ago, low-speed, small screen mobile devices on cellular networks accessed the Internet 
with minimal functionality via the Wireless Application Protocol (WAP). Now, wireless 
devices are much more powerful, in some cases as powerful as the PCs of just a few 
years ago" (Vaughan-Nichols, 2008). With the addition of these capabilities, electronic 
commerce became a user-friendly function available on mobile devices. 
1.1 Electronic Commerce (E-Commerce) 

1.1.1 Definition 

Electronic commerce (E-Commerce) is defined as "any type of business or 
commercial transaction that involves the transfer of information across the Internet" 
(Maamar, 2003). These transactions can take place between a business and person, a 
business and another business, or any combination of people and businesses. 

1.1.2 Background 

E-commerce has evolved through several major changes. First, businesses started 
with the digitization of their data to make it available online. An example of this would 
be a text-based representation of what was previously a paper-based catalog utilizing a 
service such as Compuser\'e or Prodigy. Later, businesses decided to reengineer this 
process to stay competitive. This change included increasing the ease of access to data 
and the consistency of the data presented. An example of this change would be the 
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movement of data to webpages, where standards such as HTML were used. The third 
change that occurred was the offering of onhne forms to capture users' needs efficiently 
and accurately. This involved inviting financial partners to join the shopper-vendor 
relationship. At this point, this allowed a user not to just view information, but to 
actually make a purchase from within the website. Ensuring security for the payment 
process and the exchange of private information became a concern, as now sensitive 
financial information was being transmitted and stored. 

The next stage in e-commerce was the personalization of services. This involved the 
introduction of user profiles, which included preferences and interests. The e-commerce 
site would then adapt itself to meet the customer's needs based on the user profile. Joint 
business ventures and social contexts have also been introduced into e-commerce 
(Maamar, 2003). Good examples of this would be a current website like amazon.com. 

Standards such as PCI (Payment Card Industry) were created to ensure a standard 
level of security when handling financial transactions electronically and storing the 
transactional credentials of the customers in an implemented storage system. Visa and 
Mastercard required higher standards of security from the payment card services industry, 
which created the need for standards such as PCI. The standard applies to the protection 
of credit card data that is processed, transmitted or stored. They have come up with 12 
rules that must be complied with. The requirements include encrypting card data across 
public networks and using anti-virus software These standards also include advice on 
how to develop software securely (Mathieu, 2006). 
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1.2 Mobile Commerce (M-Commerce) 

1.2.1 Deflnition 

Mobile Commerce (M-Commerce) is defined as the financial transactions for services 
or goods between trading parties through a mobile termmal (Weihui, Xiang, Haifeng, 
Weidong, & Xuan, 201 1). More precisely, a mobile terminal is defined as a smartphone 
or tablet with Internet capabilities and software to enable financial transactions. M- 
Commerce is considered by some to be the next level of evolution of e-commerce. M- 
Commerce is an emerging discipline involving applications, mobile devices, middleware, 
and wireless networks. M-Commerce involves using mobile devices such as 
smartphones and tablets to complete financial transactions. 

1.2.2 Background 

While most existing e-commerce applications can be modified to run in a wireless 
environment, m-commerce also involves many new applications that are only possible 
due to wireless infrastructure (Malloy, Upkar & Snow, 2002). As an integration product 
of electronic currency and mobile communication, mobile payment has many advantages. 
First, it is more convenient and easier to use than other traditional payment methods. 
Second, it has a higher level of compatibility due to the smaller number of providers 
(Haifeng , Xuan, Weihui, & Weidong, 2010). 
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Chapter 2: The Mobile Commerce Problem 
2.1 Standard Definition 

For years, techies and phone companies have dreamed of turning a cell phone into 
a virtual wallet (Crockett, 2005). Although there are several competing systems 
available for consumer use today, each having advantages and disadvantages, there are no 
standards established for how an m-commerce system should be implemented. The 
problem is that all of these systems are proprietary and closed. Another issue in the 
solutions available today is that these solutions are locking into individual platforms and 
will not work on competing mobile operating systems. An example of this is Google 
Wallet. The Google Wallet app is only compatible with a small number of Android 
based devices. The Google Wallet app is not available for the iOS, Windows, or 
Blackberry mobile platforms. 

2.1.1 Specification 

A standardized, open specification is needed for m-commerce systems. Current 
e-commerce and m-commerce designs need to be investigated, and a standardized model 
for how to build an m-commerce transaction processing system needs to be proposed, 
tested, and more widely implemented. 

2.1.2 Security 

Due to the sensitive nature of the data that a mobile commerce connection 
processes, a certain level of security must be added to the standard. This security will 
include several levels of data transferred across the network and the use of firewalls in 
the network to prevent the unauthorized use of that network. 
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2.1.2.1 PCI 

A standard that is in use today across the financial sector is the PCI security 
standard. There are several subsections of this standard, including the Data Security 
Standard (PCI DSS) and the Payment Application Data Security Standard (PA-DSS). 
The standard developed as part of this thesis includes the implementation of the PCI DSS 
and PA-DSS standards. If a third party certifies the system as being compliant with both 
of these standards, the mobile commerce system should be acceptable for production and 
commercial usage. 
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Chapter 3: Solution 
3.1 Mobile Commerce Open Standard 

"Open-source software development is a production model that exploits the 
distributed intelligence of participants in the Internet community" (Kogut & Metiu, 
2001). The currently available solutions are closed-source and proprietary. There are no 
mobile commerce platforms available today that are open-source and available on all of 
the major mobile platforms. An open-source standard for a mobile commerce system 
must be created to resolve this issue. 

A mobile-commerce system will require several components to be functional. 
The system must be able to handle large amounts of transactions over the Internet, it must 
be secure, and it must be reliable. There are technologies that are already in use in 
financial and e-commerce systems that can be utilized to build the open source standard. 
Tokenization, cloud computing, open source software, and open source operating systems 
will be included in the standard. 

"Tokenization involves the random generation of proxy numbers to replace actual 
credit card numbers at the point of sale to improve data security" (Heun, 201 1). 
Tokenization technology replaces a primary account number with a surrogate value 
called a "token". If a token is properly used, then there would be no need retain the 
primary account number in the payment system (Heun, 201 1). Tokenization is a method 
by which a primary account number (PAN) is associated with a reference number where 
a merchant only needs to keep the token and a trusted third party keeps the PAN and 
manages the association (Stapleton & Poore , 201 1). 
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"A cloud is a pool of virtualized computer resources" (Pareek, 2001). A cloud can 
host a variety of different workloads, such as batch style back-end jobs and user-facing 
client applications. Examples of this are a payroll processing system or an e-commerce 
website such as amazon.com. Cloud computing allows an application to be deployed and 
scaled out quickly through the rapid provisioning of virtual machines or physical 
machines; allows for support of redundant, self recovering highly scalable programming 
models; and monitors resources in real time to enable reallocation of resources when 
needed (Pareek, 201 1). Rapid provisioning is the process of deploying a server image 
onto a server through software such as VMWare or Amazon's EC2 interface. This 
process can be done in minutes, versus the hours or days it can take to complete a 
traditional server deployment. The utilization of a cloud computing system will be ideal 
for the implementation of the mobile commerce specification, as a mobile commerce 
system will require a system that is reliable, can handle large amounts of real-time 
transactions, and can reallocate resources dynamically as needed. 

"Open source software lets users study, modify, and redistribute the source code" 
(Nash, 2009). With access to open source software and operating systems, there is a 
robust collection of applications that are required to build a mobile commerce processing 
system. Webserver software such as Apache server, application servers including JBoss 
and Tomcat, and database solutions like MySQL are components that can be utilized as 
an open source implementation of the specification. 
3.1.1 Mobile Commerce Specification Definition 

The initial definition defined includes the following components: 
• System Architecture 
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• Network Architecture 

• Server Software 

• Database Definition 

• Mobile Client Specifications 

• Mobile Commerce Application Specification 

When all of these components are implemented and combined, a base model of a 
mobile commerce system is created. The system architecture describes the overall server, 
network, and software requirements. The netw^ork architecture describes how the 
network is configured for the specification. The database definition is a description of 
the tables required for the system functionality. The mobile client specification 
describes the functionality of the mobile client software. Finally, the application 
specification describes the application that implements the required back-end 
functionality of the system. 
3.1.1.1 System Architecture 

"Web-based e-commerce applications commonly employ multiple tiers (3-tier client 
server architecture) and a combination of technologies such as HTML, XML, JavaScript, 
Java (JSP, Servlets), ASP, dynamic html, CGI, and relational databases" (Meshram & 
Rane, 2012). The proposed system architecture shall consist of a 3-tier architecture. The 
top layer will contain multiple webseiTers, which will be load balanced by a top-level 
load balancer. The top-level load balancer will receive traffic from the mobile clients 
over the Internet and divide the traffic between the webservers. The middle layer will 
consist of several servers that will run the mobile commerce application. This layer will 
be load balanced by a load balancer connected between the top and middle tiers. The 



9 



database component of the system will be located in the bottom tier of the system. A 



replication method that will make multiple copies of the database simultaneously will be 



implemented. 



Presentation tier 

The top -most level of the application 
is the user interface. The main functton 
of the interface is to translate tasks 
and results to son^ethir»g the usef can 
understand 



Logic tier 

This layer coordinates the 
application, processes commands, 
makes Irjgxai decistons and 
ev3iuatK>ns, and performs 
calculations- it also moves and 
processes data between the two 
surrounding layers. 



Data tier 

Here irforn^ation is stored and retr 
from a database or file system Th 
information is then passed back tc 
logic tier for processing, and then 
eventually back to the user. 



Figure 3.1: 3 Tier Architecture Diagram 

A common technology stack should be utilized to simplify and to keep the 



implementation consistent. This should be done, as it is a normal practice to implement a 



technology stack using common technologies that were developed to function together. 



For example, an IIS webserver should not be used in combination with a JBoss 



application server. The recommendation is to utilize all Java-based technology in one 



stack, or to use all Microsoft technology in the implementation stack. Common examples 



of this type of implementation would be an IIS webserver instance, a Windows Server 



instance running IIS as an application server, and a Microsoft SQL webserver instance. 



The Java-based example of this implementation would be an Apache webserver instance. 



a JBoss or Tomcat application server instance, and an Oracle, MySQL, or IBM DB2 



database server instance. 




^ fifTUSTOFAU ADDALLSAUS 
SALES MADf TOGETHER 
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Storage 

Database 
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3.1.1.2 Network Architecture 

A three-tier networking architecture was the standard utiHzed for this 
implementation. Load balancers were used to ensure that an even amount of 
transactional data flows to and from the available web, application, and database servers. 

Firewalls were implemented between each of the tiers and in between the Internet 
and the top tier. Only the ports required for communications between the layers were 
opened, all other ports were closed. This network can be implemented either with an 
internal network, enterprise network, or with a cloud service, such as Amazon Web 
Services (AWS) or Microsoft Azure. 

3.1.1.3 Database Specification 

The underlying database for the system was implemented using the relational 
diagram and table definitions shown below. 

Token 



Devke 



-n ... 1- 



User 



-1 





Trarisaction 


n 





Figure 3,2: Databafie Relational Diagram 



Table Transaction 



id 


timestamp 


amount 


transactionType 


tokenid 


authNumber 


result 

















Table 3,1: Tra/isactioii T'^ble Defmilion 
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Table Device 




Table :?.2: Device Table Definition 



Table User 



id 


username j password 


name 


address j city 


state 


zipCode 


phone 


email 




i 




; 


L 









Table 3.3: UserTabse Di-fijiitior. 



Table Token 



id j tokenNumber 


toi^enExp 


userld 


cardType 


i 









Tabic 3A: Token Tab<e DefimVmn 

3.1.1.4 Application Specification 

The application was designed to liandle communication between the mobile client 
and the financial processor. The application managed the storage of transactional data. 
The application could be implemented in any language, but the sample of the 
implementation of the specification was implemented in Java. The application itself ran 
on a JBoss server implementafion. Communication between the mobile client and the 
application was implemented as a Webservice. The Webservice was inifially 
implemented using a SOAP-based protocol, but future implementations will support a 
Representational State Transfer (REST) implementation, utilizing JavaScript Object 
Notation (JSON) to encapsulate the data transferred. 

"JSON is a popular format for data serialization. Programmers use it extensively 
to encode data for transfer between a server and an Asynchronous JavaScript and XML 
(AJAX) application, to connect two servers communicating via Web services, and in 
many other similar scenarios. The most common structures used in programming are 
scalar variables, linear lists, and key-value pairs. JSON represents these structures in the 
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most natural and direct serialization, greatly reducing the impedance mismatch between 
in-memory structures in applications and the serialization format. JSON is not only 
convenient but also efficient" (Severance, 2012). 

The webserver was responsible for implementation of the SSL protocol to encrypt 
the data between the mobile client and the server m-commerce gateway. Client 
certificates were implemented along with the SSL certificate to employ an additional 
layer of security. 

The server application implemented the following functionality: 

MotrilteCcHiim#r€tWS \ 

' ^nandalWebSarvic8:Sef¥iOTSoapProxy 

+ heartbaatO t 

+registerUser(usemame, password, name, address, city, state. zipCode, phone, emaii:lnteger j 

I 4-registerDevioe(devioeld, status, usarld}:lnteger j 

^ ^registerTDken(cardNym, cardExp, cardType. yser!d):lntegef 

-^saleTfansaction^usarld. tokenld, amount merchant):String | 

j -fvoidTfansactiontuserld, tokenild, transactionld. marchant):String j 

Figure 3.3: Mobile Commerce Implementation UML Diagram 

Authentication 

Register User - a user is registered with the system. A user will be able to register 
multiple devices under the same usemame. A usemame must be unique and cannot be 
duplicated. This limitation was enforced at the database level and not at the mobile client 
application level. 
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Register Device - the mobile device will register itself with the application. Each device 
shall supply a unique identifier based on the device in question. The uniqueness of the 
identifier will be enforced at the database level. This identifier is a 50 character 
maximum alphanumeric string that can also include special characters. 
Register Token - any credit card number associated with a user is tokenized through a 
third-party tokenization system. The returned token will be stored in the database and the 
original number will only be utilized one time to obtain the token. Credit card numbers 
will not be stored by the system, only the tokenized value. 
Execute Transaction 

Sale - a mobile device will request the application to complete a sale transaction. The 
result from the transaction will store the authorization number for the transaction in the 
transaction table if the transaction was successful. The transaction result will be retuned 
as the result of the webservice call. 

Void - a mobile device will request the application to complete a void of a previously 
completed transaction. The authorization number of a previously successftil sale or 
refund transaction will be required to execute a void command. 

Refund - a mobile device will request the application to complete a refund transaction. 
A successful refund transaction will store the results of the transaction in the transactional 
database and return the results to the webservice caller. 

Multi-Pay Tokens 
The original concept of the token meant that the merchant could not use this 
random number to perform, a subsequent financial transaction, because it is not a valid 
PAN. However, a multi-pay token adds the ability to perform an authorized financial 
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transaction under strict control measures within the merchant environment. The merchant 
submits a token that it already has on file for a specific consumer/card to the transaction 
processor who accesses an external database to retrieve the PAN and complete the 
transaction. By using this type of token in the payment authorization process, the 
merchant reduces the risk of having the real PAN stolen as it is being collected from the 
consumer or stored by the merchant. 

"Multi-pay tokens are especially valuable in e-commerce and other card not present 
(CNP) environments that tend to store payment card information in a virtual wallet or on 
their website for repeat customers. The multi-pay token allows a merchant to tokenize the 
payment card information, associate that token with the consumer profile stored on the 
merchant side, and then use the token wdth the processor gateway that holds the token 
vault in order to run subsequent transactions. This is done without the need to prompt the 
customer for his card account number again, and without having to store the actual card 
number" (How Multi-Pay Tokens, 2012). 
3.1.1.5 Mobile Client Specification 

The mobile client will implement all of its functionality through the 
implementation of the mobile commerce webser\ace. This revision of the specification 
does not specify what the interface must look like, but only what minimum functionality 
is required to be compliant with the specification. 

A mobile client can be implemented in any programming language. A language 
native to platform, such as Objective-C for iOS or Java for Android, is acceptable. A 
fully web-based approach is acceptable, as the state of the application is handled solely 
on the server side. A hybrid approach, where the interface is built upon web standards 



15 

and only portions of the code are implemented in a native language, is acceptable. An 
example of a framework for this approach would be PhoneGap or Xamarian. PhoneGap 
and Xamarian are two examples of HyperText Markup Language (HTML) based 
frameworks that can be used to produce mobile applications. 

The mobile client must implement an interface to collect user input for use with 
the mobile commerce webservice. The results from the mobile commerce webservice 
must be interpreted and displayed in a user-friendly manner for the end-user. A platform- 
independent algorithm is required for the creation of a unique identifier for the devices. 
The Universally Unique Identifier (UUID) identifier standard was utilized as the device 
identifier in the implementation. The initial implementation will put no restrictions on 
the type of characters used for the usemame and passwords for the users. Alphanumeric 
and special characters were acceptable when creating a usemame and password. In the 
initial implementation, the password was passed without encryption, and was stored in 
the database without encryption. This feature is outside of the scope of the initial 
specifications and will be included in a later revision. 

3.2 Implementation 

3.2.1 System Implementation 

The sample implementation used an Apache webserver for all of the webserver 
instances. For the operating system of the implementation instances, default configured 
Amazon EC2 Linux instances were utilized. To implement the firewalls, Amazon's soft 
firewall service was implemented. The port of 443 was the only port the top load 
balancer allowed traffic to travel over. The top and middle layer only allowed port 5634 
to open to allow traffic between the application and the webservers. Port 2674 was the 
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only port opened between the middle and bottom layer, allowing data to be transferred 
between the application and the database. 
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Figure 3,4: Amazon FC2 Server Instances 

3.2.2 Network Implementation 

Load balancers are one of the unique features of cloud computing and implemented in 
Amazon's EC2. EC2 includes a load balancer in which an auto-scaling algorithm is used 
based on threshold values of network traffic. When the setup threshold value is exceeded, 
Amazon's EC2 will spin a new webserver and automatically roll it into the load balancer 
pool. Similarly when the traffic falls below the threshold value, Amazon will take a 
server from the allotted pool (Anandhi & Chitra, 2012). To maximize the effectiveness 
of the Amazon load balancer, it is important to split the instances in the load balancer 
evenly between the 4 available zones. If it is possible, instances should be added in 
multiples of 4, with one instance added to each zone simultaneously. 
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Figure 3.5: Amazon Load Balancer 

"Amazon EC2 provides a complete firewall solution; this mandatory inbound firewall 
is configured in a default deny mode and the Amazon EC2 customer must explicitly open 
any ports to allow inbound traflTic. The traffic may be restricted by protocol, by service 
port, as well as by source IP [Internet protocol] address (individual IP or classless inter- 
domain routing block). The classless inter-domain routing (CIDR) block was created to 
do away with the restrictive Class A, B, and C network distinction" (Passmore, 1994). 
Class A, B, and C network divisions are used to assign groups of IP addresses in a 
standardized fashion. 

"The firewall can be configured in groups permitting different classes of instances to 
have different rules, for example the case of a traditional three-tiered web application" 
(Jamil, 2011). 
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Figure 3.6: Amazon EC2 Firewall Rules 

3.2.3 Database Implementation 

The following is the definition for the database tables. All credit card numbers 
stored in the system were tokenized, a non-tokenized option was not available, and 
tokenization was not enforced. 

As part of the standard, a standard for interconnecting the database to the 

application is recommended. The sample implementation used Hibernate for its database 

API. Hibernate is a collection of related projects enabling developers to utilize plain old 

Java objects (POJO) style domain models in applications (hibemate.org, 2013). 

The following is the Entity Relationship Diagram (ERD) for the database 
implementation: 
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d INTi ir. 
, usemame VARCHAR(50) 
. password VARCHAR(50) 
> name VARC H AR( 1 00) ^ . 

address VARCHAR(IOO) 

city VARCHARC 100) 
. state CHAR{2) 
. 2^odeVARCHAR(10) 

phone VARCHAR{10) 

emai! VARCHAR(2S5) 



PRIMARY 
usemame U 
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Deviceld U 

userld 



Ki INTM1) 
. tol(^Numbef VARCHAR(50) 
tii^&nExp VARCHAR(IO) 
^ ^userld INT(11) 
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tokenNunr^f U 
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d INini) 
> timestamp TIMESTAMP 
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tran&act!onTv?>B VARCHAR|25) 
% toltenW INT(II) 

auttrNumbet VARCHAR{50) 
,^fesuitCHAR(3) 



IT 


PRIMARY 









Figure 3.7: Database ERD 



Amazon Relational Database Service (RDS) was used to create the database 
instance in the implementation. This was done so that a server instance with a MySQL 
database instance already pre-installed and pre-configured could be spawned quickly. By 
using the Amazon RDS service instead of creating an EC2 instance and manually 
installing a MySQL server, a Graphical User Interface (GUI) is made available for 
managing the server instance. To ensure that enough simultaneous connections are 
available for the system, a database instance of the type shown in figure 3.8 w^as used. 
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High-Memory Quadruple Extra Large DB Instance: 68 GB of memory, 
26 ECUS (8 virtual cores with 3.25 ECUs each), 64-bit platform, High 
I/O Capacity, Provisioned lOPS Optimized: 1000Mbps 

One ECU provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 
Opteron or 2007 Xeon processor. 



Figure 3.8: DB instance Specifications 
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Figure 3.9: Amazon RDS Database Console 



3.2.4 Application Implementation 

The application communicates with the mobile client by way of a webservice. 
By submitting a webservice request via a POST call or SOAP request, the mobile client is 
able to make transactional and account requests. The following URL is the link utilized 
by the mobile client to communicate with the mobile commerce application: 

Webservice WSdl URL: http://mobilecommercexode-sandbox.org/Mobi!eCommerceWS/MobileCommerceWS?wsdl 



The following are the descriptions of the implemented webservice class: 
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/** 

* public String heartbeat 

* method for announcing the appHcation is active 
* 

*/ 

@WebMethod() 

public String heartbeat(); 

Figure 3.1.0: Method Heartbeat Implementation 



* public String saleTransaction 

* method for announcing the application is active 
* 

* @param userld - userld from the database of the current user 

* @param tokenid - tokenid from the database of the current token(tokenized credit 
card) 

* @param amount - amount of the transaction 

* @param merchant - email address of the merchant the transaction is completed with 

*/ 

@WebMethod 

public String saleTransaction( Long userld, Long tokenid, String amount, 
String merchant) throws RemoteException; 

Figure 3 A t: Method SaleTransaction Implementation 



* public String voidTransaction 

* method for a void transaction type 
* 

* @param userld - userld from the database of the current user 

* @param tokenid - tokenid from the database of the current token(tokenized 
credit card) 

* @param transactionid - transactionid from the database of the transaction to 
be voided 

* @param amount - amount of the transaction 

* @param merchant - email address of the merchant the transaction is 
completed with 

*/ 

@WebMethod 

public String voidTransaction(Long userld. Long tokenid. Long transactionid. 
String merchant) throws RemoteException; 



Figure 3. 1 2: Method VoidTransaction implementation 
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/** 

* public String reflindTransaction 

* method for a refund transaction type 
* 

* @param userld - userld from the database of the current user 

* @param tokenid - tokenid from the database of the current token(tokenized 
credit card) 

* @param amount - amount of the transaction 

* @param merchant - email address of the merchant the transaction is 
completed with 

*/ 

@WebMethod 

public String refundTransaction( Long userld, Long tokenid, String amount. 
String merchant) throws RemoteException; 

Figure 3J.3: Melhod RetypdTransaction implementation 



* public int registerDevice 

* method for registering a mobile device with the system 
* 

* @param userld - userld from the database of the current user 

* @param deviceld - deviceld for the device being registered 

* @param transactionid - transactionid from the database of the transaction to 
be voided 

* @param status - status of the device, true = active, false = inactive 

*/ 

@WebMethod 

public int registerDevice(Long userld. String deviceld. Boolean status) 
throws RemoteException; 



Figure 3/14: Method RegisterDevice hnpiementation 
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* public int registerUser 

* method for a registering a user with the system 
* 

* @param usemame - usemame requested, will throw an exception if the 
usemame is already taken 

* @param password - password requested 

* @param name - name of user 

* @param address - address of user 

* @param city - city of user 

* @param state - state of user 

* @param zipCode - zip code of user 

* @param phone - user phone number, xxxxxxxxxx formatted 

* @param email - email address of user 
*/ 

@WebMethod 

public int registerUser (String usemame. String password. String name. 

String address. String city. String state. String zipCode, String phone. 
String email) throws RemoteException; 



Figure 3.15: Method RegisterUser Implementation 



* public int registerToken 

* method for registering an tokenizing a credit card 

* @param userld - userld from the database of the current user 

* @param cardNum - card number of the credit card 

* @param cardExp - card expiration date of the credit card, mmyy formatted 

* @param cardType - credit card type, valid values are 'Visa', 'Mastercard', 
'American Express', 'JCB', 'Discover', 'Diners Club' 

*/ 

@WebMethod 

public int registerToken(Long userld. String cardNum, String cardExp, 
String cardType) throws RemoteException; 



Figure 3.16: Method RegisterToken Implementation 



3.2.5 Mobile Client Implementation 

A native Android app was built as a sample mobile client. The mobile client was 
built using the standard Android development environment. Eclipse. The app has all of 



the basic system functionality. This includes the ability to register the user, register the 
device, register a credit card (includes tokenization), and to execute a financial 
transaction (sale, void, or refund). 



JSaObjcct ofej « aw JS3N0bject(ser^a\Me<Obj): 



thi».tnttru<:tar«ai»< * abj .9ctStrM«fl<^a»t»-avtar.a 



Figure 3.17: Eclipse IDE. Android Development Environmenr 
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Chapter 4: M-Commerce Open Standard Evaluation 

4.1 System Test 

An implementation of the first draft of the standard was built for the purpose of 
demonstrating the capabilities of the system. Tests for the capacity of the system and 
standard security tests were carried out to test the capabilities of the initial 
implementation of the standard. 
4.1.1 Load Testing 

The first test is a transaction capacity test. The number of webservers were 
changed between 1 server minimum, and up to 4 servers maximum. The number of 
application servers were changed between 1 server minimum and up to 4 servers 
maximum. The test produced 16 sets of results. Each set of results contained the 
minimum number of transactions per second, the maximum number of transactions per 
second, and the average number of transactions per second. The tests were completed 
with 10,000 simultaneous users. This test was completed via the SoapUI application to 
simulate connecting to the service with a large number of clients, and to collect the 
results. "SoapUI is a free and open source cross-platform Functional Testing solution. 
SoapUI allows easy creation and execution of automated functional, regression, 
compliance, and load tests" (What is SoapUI, 2013). 

The second test was comprised of attempts to compromise the sample 
implementation at multiple levels. At the top layer, a Denial of Service attack was 
committed with 1-4 webservers in service in combination with 1-4 application servers in 
service. The test was also comprised of attempts to access the servers in each layer 
directly. 
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4.1.1.1 SoapUI 

SoapUI was used once again to simulate 25 simultaneous users connecting to the 
system. The write capabilities of the system was examined by having all 25 test clients 
run sales transactions, refund transactions, void transactions, and registration 
transactions. These tests were done to test the write capabilities of the system. 
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Figure 4.1: SoapUI GUI Iiitei ftcice 

4.1.2 Denial of Service Testing 
4.1.2.1 slowhttptest 

A Unix line-command utility called slowhttptest was used to run denial of service 
tests on the implemented system. For all tests, 5000 simultaneous connections were used. 
The slow headers and slowloris tests were run over a time period of 240 seconds. 

The slow headers test slows down the transmittal of the http header, which locks a 
connection to the webserver for a longer than normal time period. This can create a 
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scenario where no connections to the webserver are available, causing the webserver to 
lock up and be non-responsive to the end-user. 

''Slowloris holds connections open by sending partial HTTP requests. It continues 
to send subsequent headers at regular intervals to keep the sockets from closing. In this 
way webservers can be quickly tied up. In particular, servers that have threading will tend 
to be vulnerable by virtue of the fact that they attempt to limit the amount of threading 
they'll allow'XSlowris, 2013). 



t>h - 80x37 



S 4^ edwardwilliams — e<:2-userf)ip>-10-2O2«-39<-4S 

Ecwards-MacBook-Pro:-- ecwarcwilliam<$ s lowhttptest http: //inobileconvmerce. code-S3 
ndbox.org/MobileCo.^^^erceWS/MobileCo?nmerceWS?wsdl''n?T!erceWS?w5dl 
Fri Har 29 18:12:38 2013: 
Using: 
test type: 

number of connections: 
URL: 
verb: 

Content-Length header value: 
follow up data max si2e: 
interval between follow up data: 
connections per seconds: 
probe connection tiweout: 
test duration: 
using proxy: 
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http://localhost/ 
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68 
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58 

5 seconds 
248 seconds 
no proxy 



Fri Mar 29 10:12:38 2013:slow HTTP test status on 0th second: 
initialising: 0 
pending: 1 
connected: 0 
error: 0 
closed: 8 
service available: YES 
Fri Mar 29 18:12:39 2813: 
Using: 
test type: 

nu<rber of connections: 
URL: 
verb: 

Content-Length header value: 
follow up data max size: 
interval between follow up data: 
connections per seconds: 
probe connection timeout: 
test duration: 
using proxy: 

Fri Mar 29 18:12:39 2813:Test ended on 1th second 
status: Connection refused 
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Figure 4.2: Slowhrtptest Interface 
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4.2 Test Results 

4.2.1 SoapUI Load Testing Results 
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Table 4 J: SoapUJ Test Results 



The results of the testing yielded several interesting results. First, the number of 
transactions was severely limited based on the type of transaction being executed. The 
system is able to handle over 5000 concurrent connections when executing the heartbeat 
or user registration webservice commands. The heartbeat command's only function is to 
return a pre-determined response from the service so that the client can recognize that the 
application is functional and reachable over the internet. Any webservice calls made 
where a webservice call to the payment processor was required caused the transactions 



per second to be limited to approximately 15 transactions per second. Any attempt to 
execute a test with more than 1 00 concurrent threads would overload the capacity of the 
test implementation and cause all four of the JBoss application servers to crash. This 
result was only achievable when two or more webservers were in service with the load 
balancer. With only one webserver in service, the application was only able to process 
approximately 7-9 transactions per second. By having more than one webserver, the 
transactions per second effectively doubled, but did not increase when a third and fourth 
webserver instance were added to the tier one load balancer. Adding more webservers 
decreased the average response time of the application in a linear fashion. The minimum 
response time stayed fairly constant across all tests, only the maximum response time 
decreased with an increase in the number of webservers put into service. The additional 
application servers appeared to have little to no effect on the system. With a financial 
transaction processor that could handle more simultaneous transactions, perhaps a greater 
significance in the number of application servers in service would have made a 
difference. One important thing to note is that even though having multiple application 
servers in service didn't increase the transactions per second, it does allow the system to 
have redundancy. All of the application instances utilized were located in different data 
centers (east la, east lb, east Ic, east Id). East la, lb, Ic, and Id are all located in 
northern Virginia. In its current configuration, the application could continue to run 
effectively if 3 out of 4 of the application servers failed. 
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4.2.2 Denial of Service Testing Results 

The results for the slow body Denial of Service tests show^ed a loss of service 
availability at 32 seconds, 86 seconds, and finally at 96 seconds. The webservice had a 
total failure at 108 seconds. 
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Figure 4.3: SLOW BODY Test, 5000 Connections 

The slowlowris test resulted in the webservice being unavailable at several 
intervals during the test, occurring at 36, 72, 109, 146, 164, 182, 200, and 218 
seconds. The test did run through the entire 240 second interval, so the webservers 
we able to withstand the test. 
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Chapter 5: Conclusions and Directions for Further Work 

5.1 Conclusions 

A base mobile wallet system was created successfully and the system was tested 
for load balancing and denial of service attacks. The sample implementation could be 
used successfully to register a user, register a device, register a credit card, and then use 
that tokenized card to execute several financial transactions. 

Even though this implementation is functional, there is much further work that needs 
to be done to improve both the specification and the sample implementation. 

5.2 Future Work 

5.2.1 Improved Transaction Processor 

The implementation of the specification for this thesis was severely limited by the 
performance of the transaction processor used. The account used for this implementation 
is a demo account and not a full production account. Using this approach allowed for a 
valid set of transactional responses, but the demo system's performance is severely 
limited compared to the production system. According to the processor, the demo system 
only has one webserver and one application server instance in its implementation. The 
production server has over 6 times the server capacity of the demo system. Another 
limitation is that the demo system throttles the maximum possible transaction throughput 
to help prevent overloading the system. 

5.2.2 Adding Encryption 

A sufficient encryption protocol is required for the storage of the password in the 
database. Currently, the passwords are being stored unencrypted in the database. Also, 
an SSL certificate should be added to all of the webservers in the system. This is 
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required to ensure that the data between the mobile device and the mobile commerce 
system is encrypted. Another suggestion would be the addition of client certificates. By 
modifying the mobile commerce system to deliver client certificates on a per-device 
basis, an added level of security could be added to the specification. Also, multi-layer 
security could be added. Requiring a password and some other secondary form of 
identification is an example of this. 

5.2.3 PCI Compliance 

Adherence to PCI standards was not implemented in the sample implementation 
due to time constraints and cost. A future implementation should follow these guidelines 
to be considered commercially usable. Assistance from a third party company that 
certifies systems for PCI compliance would most likely need to be a part of any sample 
implementations. 

5.2.4 Additional Samples 

An Android native client was built for this sample implementation, but in future 
revisions it may be a good idea to implement mobile clients for other mobile operating 
systems, such as iOS or Windows Mobile. Eventually, there should be a base sample 
available for every major mobile OS and a fully HTML-based sample. 
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